Security monitoring

ABSTRACT

Disclosed are systems, apparatus, methods, and computer readable media for determining a confidentiality for a site record. In one embodiment, a site record for analysis is identified at a computing device. The computing device may identify a source for the site record and determine, based on the source, a source-based confidentiality for the site record. The computing device may identify, based on the site record, a designated confidentiality for the site record, and determine that the designated confidentiality is different from the source-based confidentiality. Responsive to the determination that the designated confidentiality is different from the source-based confidentiality, the computing device may store the source-based confidentiality for the site record on a storage medium.

PRIORITY AND RELATED APPLICATION DATA

This application is a continuation of and claims priority tocommonly-assigned and co-pending U.S. patent application Ser. No.13/047,544 (Attorney Docket No. SLFCP008A/354US2), entitled “SECURITYMONITORING,” filed on Mar. 14, 2011, which is hereby incorporated byreference in its entirety and for all purposes, and which claimspriority to Provisional U.S. Patent Application No. 61/334,312, filed onMay 13, 2010, entitled “Methods and Systems for Identifying MaliciousCode in an On-demand Service Environment”, by Dapkus et al., which isincorporated herein by reference in its entirety and for all purposes.

TECHNICAL FIELD

The present disclosure relates generally to on-demand services providedover a data network such as the Internet, and more specifically tosecurity monitoring.

BACKGROUND

Organizations typically employ many different types of software andcomputing technologies to meet their computing needs. However,installing and maintaining software on an organization's own computersystems may involve one or more drawbacks. For example, when softwaremust be installed on computer systems within the organization, theinstallation process often requires significant time commitments, sinceorganization personnel may need to separately access each computer. Onceinstalled, the maintenance of such software typically requiressignificant additional resources. Each installation of the software mayneed to be separately monitored, upgraded, and/or maintained. Further,organization personnel may need to protect each installed piece ofsoftware against viruses and other malevolent code. Given thedifficulties in updating and maintaining software installed on manydifferent computer systems, it is common for software to becomeoutdated. Also, the organization will likely need to ensure that thevarious software programs installed on each computer system arecompatible. Compatibility problems are compounded by frequent upgrading,which may result in different versions of the same software being usedat different computer systems in the same organization.

Accordingly, organizations increasingly prefer to use on-demand servicesaccessible via the Internet rather than software installed on in-housecomputer systems. On-demand services, often termed “cloud computing”services, take advantage of increased network speeds and decreasednetwork latency to provide shared resources, software, and informationto computers and other devices upon request. Cloud computing typicallyinvolves over-the-Internet provision of dynamically scalable and oftenvirtualized resources. Technological details can be abstracted from theusers, who no longer have need for expertise in, or control over, thetechnology infrastructure “in the cloud” that supports them.

BRIEF DESCRIPTION OF THE DRAWINGS

The included drawings are for illustrative purposes and serve only toprovide examples of possible structures and process steps for thedisclosed inventive systems and methods for providing services to remoteclients. These drawings in no way limit any changes in form and detailthat may be made to embodiments by one skilled in the art withoutdeparting from the spirit and scope of the disclosure.

FIG. 1 shows a flow diagram of a method 100 for determining aconfidentiality level in a site record, performed in accordance with oneembodiment.

FIG. 2 shows a flow diagram of a method 200 for monitoring a site,performed in accordance with one embodiment.

FIG. 3 shows a flow diagram of a method 300 for identifying apotentially malicious website, performed in accordance with oneembodiment.

FIG. 4 shows a flow diagram of a method 400 for determining trust inlanguage translation, performed in accordance with one embodiment.

FIG. 5A shows a system diagram 500 illustrating architectural componentsof an on-demand service environment, in accordance with one embodiment.

FIG. 5B shows a system diagram further illustrating architecturalcomponents of an on-demand service environment, in accordance with oneembodiment.

FIG. 6 shows a system diagram 610 illustrating the architecture of amultitenant database environment, in accordance with one embodiment.

FIG. 7 shows a system diagram 610 further illustrating the architectureof a multitenant database environment, in accordance with oneembodiment.

DETAILED DESCRIPTION

Applications of systems and methods according to one or more embodimentsare described in this section. These examples are being provided solelyto add context and aid in the understanding of the present disclosure.It will thus be apparent to one skilled in the art that the techniquesdescribed herein may be practiced without some or all of these specificdetails. In other instances, well known process steps have not beendescribed in detail in order to avoid unnecessarily obscuring thepresent disclosure. Other applications are possible, such that thefollowing examples should not be taken as definitive or limiting eitherin scope or setting.

In the following detailed description, references are made to theaccompanying drawings, which form a part of the description and in whichare shown, by way of illustration, specific embodiments. Although theseembodiments are described in sufficient detail to enable one skilled inthe art to practice the disclosure, it is understood that these examplesare not limiting, such that other embodiments may be used and changesmay be made without departing from the spirit and scope of thedisclosure.

As used herein, the term “multi-tenant database system” refers to thosesystems in which various elements of hardware and software of thedatabase system may be shared by one or more customers. For example, agiven application server may simultaneously process requests for a greatnumber of customers, and a given database table may store rows for apotentially much greater number of customers.

In some embodiments, techniques disclosed herein may be used to maintainthe confidentiality and security of systems, websites, processes, andinformation provided by, hosted at, or stored at computing devicesassociated with an on-demand service provider. The on-demand serviceprovider may provide on-demand computing services to entities incommunication with the on-demand service environment.

In some embodiments, techniques disclosed herein may be used to maintainthe confidentiality of information when using various analysis tools tomonitor websites, computing services, and other sites provided by anetwork service provider. Site records for such sites may be identifiedfrom a variety of public, private, and protected sources. The siterecords may include information of varying degrees of confidentiality,including private information, quasi-private information, quasi-publicinformation, and public information. The site records may be subjectedto various analysis tools and techniques, at least some of which may beprovided by services or sources external to the on-demand serviceprovider. At least some of these services may not be fully trusted bythe service provider with at least certain types of confidentialinformation.

In some embodiments, techniques disclosed herein may be used to identifya potentially malicious website hosted by the service provider. A commonproblem for web hosting providers is dealing with websites that arecreated to deliver malicious content to host computers, conduct phishingattacks, or perform other types of malicious activities. In someembodiments, a combination of blacklist analysis, heuristic analysis,reputation analysis, and backend analysis may be used to determine alikelihood that a website is engaged in malicious activities.

In some embodiments, techniques disclosed herein may be used to ensureor determine trust in language translation and other types oftransformations of structured resources. Structured or formatteddocuments or resources such as webpages may need to be transformed oraltered. For example, a webpage may be translated from one writtenlanguage to another written language. In some instances, a webpage maybe sent to an external service for transformation. The external servicesmay not be controlled by or fully trusted by the on-demand serviceprovider. However, written language translation or other transformationmay occur after content has been processed into a format that includeboth content and control elements. For example, some formats like HTMLinclude active code elements with control portions that are not visibleapparent but that could potentially perform malicious actions. If aresource is transmitted to an untrusted party for translation, theuntrusted party can perform malicious alteration of the invisiblecontrol portions along with the language translations. These changescould then perform malicious actions after inclusion of the resourceinto a larger software system or website.

FIG. 1 shows a flow diagram of a method 100 for determining aconfidentiality level in a site record, performed in accordance with oneembodiment. In some implementations, an on-demand service provider mayevaluate site records associated with sites accessible via the on-demandcomputing services. These sites may include computer systems, programs,configurations, web sites, or any other computing services constructs.

In some embodiments, the site records may include any information aboutthe sites. For instance, the site records may include URLs leading tothe sites, cached copies of sites, backend logs associated with thesites, IP addresses leading to the sites, internal audit trails of sitecreation or access, or any other site-related information.

In some implementations, the on-demand service may evaluate site recordsfor various reasons. For instance, the on-demand service provider mayseek to identify malicious or prohibited sites. As another example, theon-demand service provider may seek to identify sites that areinadvertently leaking private information. As yet another example, theon-demand service provider may seek to identify sites that have beenhijacked, altered, or otherwise attacked by malicious entities.

In some implementations, site records can contain sensitive informationsuch as URL parameters, database keys, usernames, passwords, customerinformation, addresses, social security numbers, and various other typesof information. In some embodiments, the on-demand service provider maybe explicitly or implicitly obliged to maintain the confidentiality ofsuch information. The information may include information private to theon-demand service provider itself or information private to entitiesaccessing computing services provided by the on-demand service provider

In some embodiments, the degree of confidentiality that informationcontained in site records is afforded by the on-demand service providermay be based at least in part on where the information is discovered.For instance, data discovered in internal server logs or audit trailsmay be afforded a relatively high level of confidentiality unless thereexists some reason to believe that the information is not sensitive. Asanother example, data discovered via a search conducted with a publicsearch engine such as Google® may be afforded a relatively low level ofconfidentiality since the information is publicly accessible.

Many techniques and tools for analyzing site records exist. In someimplementations, some tools may be controlled by the on-demand serviceprovider. However, techniques for detecting malicious or prohibitedsoftware may include sending information to external services. Theseexternal services may not be under the control of the on-demand serviceprovider.

Further, the external services may be trusted to varying degrees by theon-demand service provider and/or entities accessing the on-demandservices. For instance, some services may be provided by entities theservice provider has reasons to trust. These trusted entities mayinclude entities with which the service provider has had a longrelationship, entities that are publicly well-known and well-regarded,or entities that can provide assurances that they are capable ofsecurely handling confidential information. However, some services maybe provided by entities the service provider has little reason to trust.These untrusted entities may include entities with which the serviceprovider has not had a long relationship, entities that are relativelyunknown, or entities that are unable to make assurances regarding thehandling of confidential information.

In some embodiments, an external service may be assigned a trust level.The trust level may indicate the degree to which the external service istrusted by the on-demand service provider, an entity accessing servicesprovided by the service provider, or some other entity.

In some embodiments, the trust level for an external service or otheranalysis tool may be compared with a confidentiality level of a siterecord to determine whether the site record may be sent to the analysistool. Techniques for using a confidentiality level for a site record arediscussed in further detail with respect to FIG. 2.

In some embodiments, a confidentiality level for a site record may beused for various purposes, including purposes not discussed with respectto FIG. 2. For example, a confidentiality level for a site record may beused to determine when private information is being leaked, to notifyusers or entities accessing the on-demand service environment thatconfidential information has been leaked, or for any other reason.

In some embodiments, the method 100 may be performed at one or morecomputing devices operating in an on-demand service environment. Forexample, one or more operations may be performed at app servers 588 orbatch servers 584 shown in FIG. 5B. As another example, one or moreoperations may be performed by a server not shown in FIG. 5B. In someimplementations, operations may be performed on the same physicalcomputing device or at different physical computing devices operating inconcert.

In some embodiments, the method 100 may be performed periodically. Forexample, the method 100 may be periodically performed to analyze avariety of site records identified through various techniques. Themethod 100 may be run according to any schedule, such as once persecond, once per day, once per week, etc.

In some embodiments, the method 100 may be performed when a triggeringevent is detected. For example, a new site record may be discovered viasome source. As another example, a site record may be selected fortransmitting to an external service or other analysis tool for analysis.In these cases, the site record confidentiality level may be determinedprior to submitting the site record for analysis.

In some embodiments, a monitoring process may periodically analyzevarious sources to search for site records. For example, a monitoringprocess may periodically check internal server logs, conduct searchesvia public search engines, analyze communications received by theon-demand service provider, or otherwise search or monitor informationsources for site records.

At 102, a site record is identified for analysis. In someimplementations, sites may include any computer systems, programs,configurations, web sites, or any other computing services constructs.In some instances, a site may be associated with a network address, suchas an IP address, a URI, a URL, or a different type of identifier. Inother instances, more than one site may be accessed at a single networklocation, such as a portal. In still other instances, a site may not bepublicly accessible via a network and/or may include private informationinternal to the service provider.

In some embodiments, the site associated with the identified site recordmay be provided by the on-demand service provider. Alternately, the sitemay be provided at least in part by an entity accessing the on-demandservice provider, while the on-demand service provider may providehosting functionality or storage space for the site. In either case, theon-demand service provider may have access to private or protectedinformation concerning the site, such as server logs, source code,non-public data, or other such information.

In some embodiments, a site record may include any information relatedto a website or service provided by the on-demand service provider,alone or in conjunction with an entity accessing on-demand servicesprovided by the on-demand service provider. For instance, the siterecord may include a URL leading to a site, a cached copy of a site,backend logs associated with the site, an IP address leading to thesite, internal audit trails of site creation or access, or any othercontextual information or record information associated with the site.

At 104, the source from which the site record was identified isidentified. In some implementations, site records may be identified in avariety of ways and from a variety of sources. In some instances, siterecords may be identified via internal sources such as server logs,audit trails of site creation or access, or other internal information.In other cases, site records may be identified via external sources suchas an Internet search engine, a World Wide Web spider cache, a publicnetwork such as the Internet, or a publicly available information cacheor repository. In yet other instances, site records may be identifiedfrom communications received by the service provider from externalsources. These communications may include e-mails, SOAP messages, textmessages, or any other forms of communication.

At 106, a source-based confidentiality level for the site record isdetermined. In some embodiments, the source-based confidentiality levelmay be determined by comparing the source of the site record to a listof designated confidentiality levels for site record sources.Alternately, or additionally, a source type may be determined. Thesource type may reflect information such as whether the source isinternal or external to the service provider, whether the source ispublicly accessible or privately accessible, whether the source isaccessible to an entity accessing the on-demand service provider, or anyother classification information.

In some embodiments, site records may be assigned confidentiality levelsof high, medium, low, and none based on the source through which theyare identified. However, these specific classifications need not be usedin each embodiment. Instead, a classification scheme for confidentialitylevels may be strategically determined based on factors such as thetypes of sources that are used to discover site records, theconfidentiality needs and obligations of the on-demand service provider,the confidentiality needs and obligations of entities accessingcomputing services via the on-demand service provider, and any otherrelevant information.

In some embodiments, site records discovered via certain sources may beassigned a relatively high level of confidentiality. Sources that maylead to a site record being assigned a relatively high level ofconfidentiality may include internal server logs, internal auditrecords, any information known or believed to be covered by an explicitor implicit confidentiality obligation, or any other information knownor believed to be private or sensitive.

In some embodiments, site records discovered via certain sources may beassigned a medium level of confidentiality. Sources that may lead to asite record being assigned a medium level of confidentiality may includecommunications such as e-mails received by the on-demand serviceprovider, information sources believed to possibly contain confidentialinformation, and information sources not explicitly confidential butcarrying an implicit obligation of confidence or trust.

In some embodiments, site records discovered via certain sources may beassigned a relatively low level of confidentiality. Sources that maylead to a site record being assigned a low level of confidentiality mayinclude a public network such as the Internet, a public search enginesuch as Google®, and information believed (but not known) to not becovered by any obligation of confidentiality.

In some embodiments, site records discovered via certain sources may beassigned a confidentiality level of none. Sources that may lead to asite record being assigned a relatively high level of confidentialitymay include any sources known to be public or unrestricted, such asinformation published by the on-demand service provider, informationavailable via public news sources, information evaluated and identifiedas public by the on-demand service provider, information evaluated andidentified as public by an entity accessing computing services via theon-demand service provider, and any other information known to bepublic.

In some embodiments, a site record discovered from a site not covered byany other category may be assigned a default confidentiality level. Insome implementations, the default level of confidentiality may berelatively high in order to avoid inadvertently releasing publicinformation. Alternately, the default level of confidentiality may berelatively low if most information discovered in this way is believed tonot be confidential.

At 108, a determination is made as to whether the site record has apre-existing confidentiality level. In some embodiments, thedetermination made at 108 may be made at least in part by accessing astorage device, such as the storage systems 622 or 624 shown in FIG. 6.

In some embodiments, a pre-existing confidentiality record may have beenstored in a previous iteration of the method 100. For example, thepre-existing confidentiality record may have been stored at operation112 shown in FIG. 1. Alternately, or additionally, a pre-existingconfidentiality record may have been assigned in some other fashion. Forinstance, certain types of site records may be associated with adefault, minimum, or maximum confidentiality level. As another example,a previous analysis of the site record may have resulted in aconfidentiality level being assigned based on content included in thesite record, such as internal database keys.

At 110, a determination is made as to whether the pre-existingconfidentiality level is greater than the source-based confidentialitylevel. In some implementations, as shown in FIG. 1, the lower of the twoconfidentiality levels should govern. For example, suppose that a siterecord has a relatively high source-based confidentiality level becausethe site record was retrieved from an internal log. However, alsosuppose that the site record has a low pre-existing confidentialitylevel because it was previously retrieved from a publicly accessiblesource such as an Internet search engine. In this case, assigning thesite record a high confidentiality level may not reflect its publiclyaccessible nature.

Alternately, the higher of the two confidentiality levels may govern inat least some instances. For example, a site record containing privateinformation may have been inadvertently leaked and discovered via apublic source such as an Internet search engine. In this case, if theinformation has not been widely shared or accessed, a request to removethe private information may be sent to the search engine. Thus, therelatively higher confidentiality level may in some cases be maintained.

At 112, the source-based confidentiality level for the site record isstored. In some embodiments, the source-based confidentiality level maybe stored if the site record has no pre-existing confidentiality level,if the pre-existing confidentiality level is greater than thesource-based confidentiality level, or if some other condition is met.

In some embodiments, storing the source-based confidentiality level maybe performed at least in part by recording a value at a storage system,such as the storage systems 622 or 624 shown in FIG. 6. In someembodiments, information other than the source-based confidentialitylevel may also be stored. The other information that may be stored mayinclude, but is not limited to: the source on which the confidentialitylevel is based, a date or time at which confidentiality analysis waslast conducted, and/or any other contextual information for the siterecord.

At 114, the use of the pre-existing confidentiality level for the siterecord is continued. In some embodiments, continuing to use thepre-existing confidentiality level may not require any explicitoperations. Since the pre-existing confidentiality level has been storedin an accessible manner, updating the stored confidentiality level maynot be required. Alternately, one or more operations may be performedfor updating contextual information related to the site recordconfidentiality level. For instance, a date or time at which theconfidentiality level was last evaluated for the site record may beupdated.

FIG. 2 shows a flow diagram of a method 200 for monitoring a site,performed in accordance with one embodiment. In some embodiments, themethod 200 may be used to facilitate the analysis of data by one or moreanalysis tools.

In some embodiments, the data may include site records, which mayinclude information such as URIs. Data may be associated with aconfidentiality level, and an analysis tool may be associated with atrust level. In some instances, the confidentiality level for data mayexceed the trust level of an analysis tool selected for analyzing thedata.

In some embodiments, the sensitivity of the source for and/or contentsof a site record may be determined. This sensitivity may be compared tothe sensitivity of a tool to be used in its analysis. If the site recordis more sensitive than the analysis tool to be used, the site record maybe subjected to one or more sanitizing transforms that can be applied tothe site record to downgrade the sensitivity level to the trust level ofthe tool. Such transforms can include the removal of parameters meetingcertain patterns like social security numbers, scrambling or randomizingdata, changing timestamps, or any other type of modification.

However, some sites may require certain inputs to function properly.Thus, at least some transforms may recognize key inputs to sites andapply specialized techniques to maintain site function. For instance, aURI may include confidential information as parameter values. In thiscase, simply removing the confidential information may result in theanalysis tool being unable to fulfill the function requested of it. Toavoid such a situation, the site record may be transformed so that lessconfidential information is included in the site record. For example, adefault social security number such as 000-00-0000 may be substitutedfor an actual social security number associated with a real individual.In this case, the analysis tool can perform the requested analysis usingthe sample social security number.

At 202, a site record is identified for analysis. In some embodiments,operation 202 may be substantially similar to operation 102 discussedwith respect to FIG. 1. In some embodiments, a site record may includeany information related to a website or service provided by theon-demand service provider, alone or in conjunction with an entityaccessing on-demand services provided by the on-demand service provider.For instance, the site record may include a URL leading to a site, acached copy of a site, backend logs associated with the site, an IPaddress leading to the site, internal audit trails of site creation oraccess, or any other contextual information or record informationassociated with the site.

In some embodiments, site records may be identified by searching oranalyzing public information, such as World Wide Web spider caches,Internet search engines, or public repositories of information.Alternately, or additionally, site records may be identified bysearching or analyzing private information such as server logs, audittrails, or source code. Alternately, or additionally, a list of siterecords may be maintained and periodically analyzed.

At 204, a confidentiality level for the site record is identified. Insome embodiments, the confidentiality level for the site record mayinclude a level selected from the levels described with respect toFIG. 1. Alternately, or additionally, other confidentiality levels maybe used. The type of confidentiality levels to assign to site recordsmay be strategically determined based on factors such as a desired levelof security, the types of information that need to be protected, and thesecurity needs of entities accessing computing services via theon-demand computing services environment.

In some embodiments, the confidentiality level for the site record maybe determined based on a source of the site record. In this case, theconfidentiality level may be determined using the techniques discussedin relation to FIG. 1 or using other source-based confidentiality leveldetermination techniques.

In some embodiments, the confidentiality level for the site record maybe determined based on the content of the site record. For example, thesite record may be analyzed to determine whether any of the informationcontained therein includes private information such as usernames,passwords, social security numbers, or addresses.

In some embodiments, the confidentiality level for the site record maybe determined using a combination of content-based and source-basedanalysis. For instance, a site record that includes a social securitynumber may be indicated as having a relatively high confidentialitylevel regardless of the source from which it was located. As anotherexample, a site record identified via a known public source such as apublic news service may be identified as having a relatively lowconfidentiality level regardless of the information contained therein.

At 206, an analysis tool for analyzing the site record is selected. Insome embodiments, analysis tools may perform various operations foranalyzing the site record. For example, the analysis tool may perform asecurity analysis of a site record that includes a URL of a websitehosted by the service provider. The analysis performed by the analysistool may include, but is not limited to, any or all of the followingexamples. First, an analysis tool may hash a URL or other value andcompare the hashed value against a table of hash values of URLs known tobe associated with malicious activity. Second, an analysis tool maycompare an e-mail address associated with the site record with ablacklist of known bad e-mail senders such as spammers. Third, ananalysis tool may attempt to connect with a URL using securecommunications and determine whether the attempt is successful. Fourth,an analysis tool may access a URL with a vulnerable web browser such asan unpatched version of Internet Explorer® 6.0 and then determinewhether any of the web browser's vulnerabilities have been exploited.Fifth, an analysis tool may compare a URL against a cache of spideredwebsites to determine an age of the website associated with the URL.

At 208, a trust level for the analysis tool is identified. In someembodiments, the trust level for the analysis tool may correlate with aconfidentiality level associated with information, as discussed withrespect to operation 106 in FIG. 1. That is, the trust level for theanalysis tool may be determined to be a value selected from high,medium, low, and none. Alternately, the trust level for the analysistool may be a value selected from a different confidentiality/trustscale.

In some embodiments, the trust level for the analysis tool may bedetermined by retrieving the trust level from a list of predeterminedtrust levels. These trust levels may be assigned by a user such as anadministrator. Alternately, the trust level for the analysis tool may bedetermined at least in part by analyzing a source or owner of theanalysis tool. For example, analysis tools internal to the serviceprovider may be afforded a high-level of trust, analysis toolsassociated with trusted associates of the service provider may beafforded a medium level of trust, and analysis tools associated withrelatively unknown parties may be afforded no trust.

At 210, a determination is made as to whether the confidentiality levelexceeds the trust level. In some embodiments, a determination that theconfidentiality level of the identified information exceeds the trustlevel of the selected analysis tool may indicate that the identifiedinformation should not be sent to the selected confidentiality tool. Forexample, the information may include private user data such as usernamesand passwords, and the analysis tool may be provided by an externalservice associated with a relatively unknown or untrusted serviceprovider.

At 212, a transform for modifying the site record is selected. Thetransform may perform any operations for reducing the confidentialitylevel of the information contained in the site record. The transformsmay hash, encrypted, alter, replace, supplement, eliminate, scramble,randomize, or otherwise modify the information contained in the siterecord so that the site record may be safely provided to the analysistool identified at operation 208.

In some embodiments, the types of modifications performed by a transformmay include, but are not limited to: modifying social security numbers,modifying identifiers not provided by the on-demand service environment,modifying based on regular expressions, modifying usernames, modifyingpasswords, modifying timestamps, modifying parameters, and/or modifyingparameter values. Such modifications can include removing, replacing, oraltering the modified information. In some embodiments, URIs may bemodified to eliminate parameters or parameter values, eliminate allinformation except a host name, eliminate all information except an IPaddress, or eliminate any other information. In some embodiments, atransform may modify a communication protocol, such as by changing aSecure Sockets Layer (SSL) URI to a hyper text transport protocol (HTTP)URI.

In some embodiments, the transform may be selected at least in part onthe basis of a desired reduction in confidentiality level. For example,some transforms may be designated as being operable to reduce theconfidentiality level of a site record from high to medium, from high tolow, from high to none, from medium to low, from medium to none, fromlow to none, or to perform any other reduction.

In some embodiments, two or more transforms may be selected in order toeffect a greater reduction in confidentiality level. For example, afirst transform may be selected to reduce the confidentiality level fromhigh to medium, and a second transform may be selected to reduce theconfidentiality level from medium to low. As another example, reducingthe confidentiality level from high to medium may involve selecting twoor more different transforms. In some embodiments, the specifictechniques for providing and selecting the transforms may bestrategically selected based on factors such as the nature of themodification that is to be performed, the desired reduction inconfidentiality level the type of information that is to be transformed,and any other considerations.

At 214, the site record is modified in accordance with the selectedtransform. As discussed with respect to operation 212, modifying thesite record may include any operations for reducing the confidentialitylevel of the information included in the site record. These operationsmay remove confidential information, replace confidential informationwith less confidential information, encrypt or hash confidentialinformation, or perform any other modification.

In some embodiments, the transform may recognize inputs required for thefunction of some sites. The transform may apply specialized techniquesto reduce the confidentiality of required information while maintainingsite functions. For instance, the transform may substitute genericinformation for personalized information.

At 216, the site record is provided to the analysis tool. In someembodiments, providing the site record to the analysis tool may involvetransmitting the site record to an external service, sending the siterecord as input to an internal service or process, or storing the siterecord in a location where it can be retrieved by the analysis tool. Thespecific technique used to provide the site record to the selectedanalysis tool may be strategically determined based on the method ofcommunicating with and/or activating the selected analysis tool.

At 218, a determination is made as to whether to perform furtheranalysis of the site record. In some embodiments, a determination thatthe site record is to be subjected to further analysis may result in oneor more of operations 206-218 being repeated. Further analysis of thesite record may include analysis by analysis tools different than thatoriginally selected at operation 206. These different analysis tools mayhave trust levels different than that of the original analysis tool.

In some cases, the different analysis tools may have lower trust levelsthan the original analysis tool. In these cases, the site record may besubjected to further transforms in order to protect the confidentialityof the information contained in the site record. Alternately, thedifferent analysis tools may have higher trust levels than the originalanalysis tool. In these cases, information removed, replaced, orobfuscated by the transformation at operation 214 may be replaced ortransformed in a different way in order to provide the newly selectedanalysis tools with more information for analysis.

In some embodiments, analysis tools may be selected in decreasing orderof trust. In this way, the site record may be progressively transformedto have ever lower confidentiality levels to correspond with theprogressively lower trust levels without needing to revert to a higherconfidentiality level. Alternately, analysis tools may be selected in adifferent order.

In some embodiments, the determination made at 218 may be based at leastin part on the results of the analysis performed by the analysis toolselected at operation 206. For instance, the analysis tool may indicatethat the site record indicates possible problems with the site, but thatfurther analysis is necessary to confirm the problems.

In some embodiments, the determination made at 218 may not be based onthe results of the analysis performed by the analysis tool. For example,the site record may be subjected to analysis by a number of differentanalysis tools regardless of the outcome of each analysis.

FIG. 3 shows a flow diagram of a method 300 for identifying apotentially malicious website, performed in accordance with oneembodiment. A common problem for web hosting providers is dealing withwebsites that are created to perform malicious activities. For example,a malicious website may be created to deliver malicious content such asviruses, worms, Trojans, and other malicious software to host computers.As another example, a type of malicious website known as a phishing sitemay be created to trick users into divulging private information. Quickidentification and takedown of these sites has become paramount tomaintaining trust on public networks such as the Internet.

In some implementations, the method 300 may be applied in environmentswhere websites may be cheaply or freely created by users who may or maynot be known to the hosting service provider. In such environments,malicious websites may be created in a very short amount of time and,once their activities are completed, may be removed in a very shortamount of time.

In some implementations, the method 300 may be used to detect amalicious website within a short period of time after the creation ofthe website. For example, in some instances a malicious website may bedetected in a matter of minutes after its creation. However, in someinstances detecting a malicious website may take a longer amount oftime.

In some embodiments, the detection of potentially malicious websites isperformed at least in part via blacklists. Blacklists may identify knownmalicious software download sites and known bad phishing sites. However,blacklists may not protect against unknown or undiscovered maliciouswebsites. Some malicious websites may take days or weeks to beidentified as such by security vendors and placed on blacklists, or maynever be identified.

In some embodiments, the detection of potentially malicious websites isperformed at least in part via heuristics. Heuristics may includetechniques for investigating links for obfuscated URLs, references tocorporate images on domains which they do not own, analysis of pagecontent to determine if it was stolen from another domain, and otheranalysis tools. However, many currently available heuristics tools aredesigned to work on websites in which backend server information such ascommunication logs and source code are unavailable for analysis.

In some embodiments, reputation analysis may be used to determine atrust level for a user (e.g., an administrator) associated with awebsite. Reputation analysis may take into account a user's pastactivity, such as other websites created by the user.

In some embodiments, backend analysis may be used to determine a moredirect trust level for a website. The backend analysis may analyzeserver-side source code, client-side source code, communication logs,and other metadata to help in identifying potentially maliciouswebsites.

The method 300 may be used to automatically identify potentiallymalicious websites. This identification may be based on an analysis of auser associated with the creation or maintenance of the website, abackend analysis of the source code used to generate the website, and/ora backend analysis of communications conducted by the website.

At 302, a request to evaluate a website is received. In someembodiments, the request may be received at a computing device. Thecomputing device may be associated with the web hosting serviceprovider. The computing device may be used to analyze websites hosted atthe hosting provider for malicious activity.

In some embodiments, the request to evaluate the website may be receivedbased on an indication that the website is possibly malicious. Forinstance, a user such as an administrator may flag a website as beingpossibly malicious.

In some embodiments, the request to evaluate the website may be receivedas part of a regular analysis procedure. For example, the hostingprovider may periodically evaluate each or some of the websites hostedat the hosting provider to determine whether the websites arepotentially malicious. This analysis may occur every hour, every day,several times a day, or at any other time interval.

In some embodiments, the request to evaluate the website may begenerated based on a detected or automated event. For example, a websitemay be automatically evaluated when it is created, when a designatedtime has elapsed since the creation of the website, when a designatedtraffic threshold for the website has been surpassed, or when any otherdesignated event is detected.

At 304, a user associated with the creation or maintenance of thewebsite is identified. In some embodiments, the user may be identifiedby a user account at the hosting provider. For example, the user accountmay include a username and password for logging in to the hostingprovider, for accessing billing information related to the web hostingservices, or for accessing backend components associated with thewebpage. Alternately, or additionally, a user may be identified by someother technique, such as by analyzing an IP address associated with anetwork connection used to access the hosting provider.

In some instances, the user may be identified based on the creation orownership of the web site being analyzed. For instance, the user may beidentified by a user account used to create the website. Alternately,the user may be identified based on the editing or maintenance of thewebsite. For instance, one user may have created the website, whileanother user may log on to edit the website or view backend informationsuch as logs or records. In some embodiments, any or all of the userslinked to the website being analyzed may be used for trust analysis.

At 306, a first trust level for the identified user is determined. Inthe examples described herein, higher levels of trust mean that a useris more likely to be trustworthy and less likely to create a maliciouswebsite. However, in some embodiments, a risk level may be used in placeof the trust level, and a higher risk level may indicate that the useris more likely to create a malicious website.

In some embodiments, a mathematical formula or procedure for determininga trust level for a user may be strategically determined based onfactors such as the age of the hosting system hosting the website, thelength of time the hosting system has been used by users, the dataavailable to the hosting provider, the types of websites hosted by thehosting provider, and other factors. In some embodiments, one or more ofthe following considerations may be used to determine a trust level forthe identified user.

In some embodiments, new users who have recently registered with thehosting provider and who have not been identified as having createdother websites may be assigned a neutral or zero level of trust, sincevery little may be known about new users.

In some embodiments, a higher level of trust may be afforded to userswith accounts active for a greater length of time. In many cases, a usercreating a malicious website has not been registered with the hostingprovider for more than a few days or weeks. Thus, a user account olderthan a designated length of time (e.g., 6 months), may be afforded ahigher level of trust. In some embodiments, the trust level afforded tothe user may increase as a function of the age of the user's account.

In some embodiments, a higher level of trust may be afforded to activeusers of the system. In many cases, a user creating a malicious websitewill not conduct much activity with the hosting provider afterestablishing a new website and uploading malicious website code to theserver. Thus, an active user may be more trustworthy. In someembodiments, activity may be measured by the number or frequency ofchanges to the website source code, a number or frequency of logins bythe user. Alternately, or additionally, activity may be measured byusage of features provided by the hosting provider that would likely notbe necessary to use if the user were creating a malicious website. Thesefeatures may include the creation of custom database objects, the use ofcustomer relations management (CRM) features, or the creation ofworkflows.

In some embodiments, a higher level of trust may be afforded to usersbased on the past creation of other websites. In many cases, a usercreating malicious websites often may not also create non-maliciouswebsites. As more time elapses since a malicious website was created,the website is more likely to be identified as malicious. Accordingly, auser who has created or modified websites that are older than adesignated period of time and that have not been identified as maliciousor untrustworthy may be afforded a higher level of trust. In someembodiments, a threshold (e.g., 90 days) may be established for usingpast-created websites to increase a user's trust score. That is, thedevelopment of websites prior to 90 days before the trust evaluation maylead to a higher level of trust, while the development of websites after90 days before the trust evaluation may not lead to a higher level oftrust. Alternately, or additionally, a trust level of the user mayincrease as a function of the age, number, and trust level of the pastwebsites the user has created.

In some embodiments, a lower level of trust may be afforded to a userwho is associated with potentially malicious activity. In a firstexample, if the user is detected as editing a website that is deemeduntrustworthy, then the user's trust level may be lowered. In a secondexample, if the user connects to the web host from an IP address orother network location known or believed to be associated with maliciousactivity, then the user's trust level may be lowered. In a thirdexample, if the user connects to the web host via a suspected “useragent” identified via an HTTP header, then the user's trust level may belowered. In a fourth example, a user may be assigned a lower trust levelbased on a heightened request frequency, which may indicate the use of aprogram (which may also be known as a “bot” in this context) inconnecting with the web host. In a fifth example, if the user fails ahuman verification test such as providing a correct response to a“captcha” phrase, which may also indicate the use of a bot, then theuser's trust level may be lowered.

In some embodiments, operations 304 and 306 may be repeated if more thanone user is identified. For instance, one user identified in the hostingsystem may have created the website, while several other users may havebeen given permission to create or edit the website.

At 308, a second trust level is determined. The second trust level maybe based on the website source code, on communication conducted by thehosted website, on other backend considerations, or on some combinationthereof.

In the examples described herein, higher levels of trust mean that awebsite is more likely to be trustworthy and less likely to bemalicious. However, in some embodiments, a risk level may be used inplace of the trust level, and a higher risk level may indicate that thewebsite is more likely to be malicious.

In some embodiments, a mathematical formula or procedure for determininga trust level for a website may be strategically determined based onvarious factors. In some embodiments, one or more of the considerationsdiscussed in the following paragraphs may be used to determine a trustlevel for the website.

In some embodiments, the source code used to create the website may beanalyzed to determine whether the website is possibly malicious. Forexample, a determination may be made as to whether the website sourcecode includes hotlinks to remotely hosted images. As another example, adetermination may be made as to whether the website source code includessuspect text words or phrases, such as the word “login.” As yet anotherexample, a determination may be made as to whether the website sourcecode includes unauthorized use of images.

In some embodiments, the detection of content such as media or sourcecode that exists on a well-known, trusted website may decrease the trustlevel of the website. For example, if a portion of the hosted website issimilar to a portion of the website of a Fortune 100 or Fortune 1000website, then the hosted website may be involved in a phishing attack inwhich the hosted website simulates the well-known website in an attemptto elicit private information from users of the hosted website.

In some embodiments, the detection of links from the website to knownmalicious websites may decrease the trust level of the website. Forinstance, the source code used to create the website may be analyzed todetermine if it contain links to known malicious sites. As anotherexample, the website as served to client machines (e.g., the client-sidecode) may be analyzed to determine if it contain links to knownmalicious sites.

In some embodiments, the detection of links from the website towell-known, trusted websites may increase the trust level of the hostedwebsite. For instance, links to Fortune 100 or Fortune 1000 websites mayindicate information or business activities rather than maliciousactivities.

In some embodiments, the detection of a login page on the website otherthan a login page provided by the hosting provider may decrease thetrust level of the website. Such pages may be indicative of phishingactivities in which an author of the malicious website is attempting toelicit private login information from users of the website.

In some embodiments, the detection of links from the website toexecutable files, batch files, or other files that may be executed by aclient machine may decrease the trust level of the website. Executablefiles may include viruses, worms, spyware, Trojans, or other malicioussoftware. Thus, the source code used to create the website may beanalyzed to determine if it contain links to executables.

In some embodiments, a website that is edited over a period of time maybe afforded a higher level of trust. In many cases, malicious websitesare created in a short period of time and then eventually discarded.That is, a user may upload a file or set of files to the web hostingprovider and make only minimal changes to the files. In contrast,developers of non-malicious websites often make many changes to thewebsites over many days. Thus, activity editing or modifying the websiteover a period of time may improve the trust level for the website. Oneexception to this rule is that some websites may have a developmentsystem in which the website is edited and modified and a productionsystem in which the website is provided to end users. The presence ofsuch a setup may be identified by receiving an explicit indication froma user, by detecting an interlinking between different hosted addresses,or by any other mechanism. If the presence of such a system is detected,then a lack of editing on the production account may not be treated asreducing a level of trust in the website.

In some embodiments, the detection of obfuscation techniques may reducethe trust level of a website. Obfuscation techniques may include anyprocedures or mechanisms to conceal the source code used to generate adisplayed webpage, conceal communications involving the webpage, concealdata communicated by the webpage, or conceal any other aspect of theoperation or creation of the webpage. In many cases, obfuscationtechniques are used by malicious website operators in order to confuseclient side security tools and/or users attempting to reverse engineerthe inner workings of the website. In some embodiments, obfuscationtechniques may be detected by identifying the presence of JavaScript®unpacking routines, code that hides references to commonly usedJavaScript® functions, or unusual patterns in function calls (e.g.,relatively high numbers of calls to eval( )).

In some embodiments, a website that imposes a condition on rendering maybe afforded a lower level of trust. A condition on rendering includesany conditional mechanism by which a website appears differently basedon the identity of a user requesting the website, an identity of aprevious website visited by the user, an identity of a network locationfrom which the request for the website originated, an identity of a webbrowser from which the request for the website originated, or on someother factor.

For example, a malicious website may use a phishing attack to solicitprivate data from users associated with a legitimate website, such aseBay. In this case, the malicious website may appear to have a userinterface similar to eBay to trick users into divulging their usernamesand passwords. However, if eBay employees were to investigate themalicious website, then the ruse would be quickly detected. Thus, themalicious website may impose a condition in the source code used togenerate the malicious website. The condition may specify that if arequest for the malicious website is received from a server associatedwith the legitimate website, such as eBay, then the malicious websiteshould render as a benign website so that a service provider of thelegitimate website does not detect the malicious activity.

As another example, a malicious website may display contentconditionally based on the web browser used to view the website. In thiscase, malicious content may be provided to browsers that haveexploitable security flaws, while non-malicious content may be providedto more secure browsers. Web browsers that have exploitable securityflaws may include older versions of web browsers that have not beenupdated to include security patches and other protections afforded bymany new web browsers

In some embodiments, a condition on rendering may be detected byanalyzing the source code used to create the website, by comparing therendered website in response to requests from different requesteraddresses, or by some other technique. If a condition on rendering isdetected, then the trust level afforded to the website may be reduced.

In some embodiments, communication between the hosted website andexternal servers may affect the trust level in the hosted website. Insome cases, such communication may be used by malicious websites totransmit information acquired through phishing, to download newmalicious software for sending to host computers, or to receiveinstructions for malicious activities. However, non-malicious websitesmay also communicate with external websites for various legitimatereasons. Accordingly, the communication between the hosted website andexternal servers may be analyzed to determine whether it is indicativeof malicious activities.

For example, communication with known good servers such as websitesassociated with Fortune 1000 companies is unlikely to indicate maliciousactivity. On the other hand, communication with IP addresses or networkshares indicate that malicious activity may be occurring. Likewise,communication over non-standard ports (e.g., ports other than ports 80and 443) may indicate malicious activity. Further, communication withservers known to be associated with malicious activity may provide anindication of malicious activity by the hosted website.

At 310, a combined trust level is determined. In some embodiments, thecombined trust level may be based on the first and second trust levels.The technique used to create the combined trust level may bestrategically determined based on the data ranges used to create thefirst and second trust levels. For instance, the first and second trustlevels may each be values on a scale of 0 to 1, where 0 indicates alower level of trust and 1 indicates a higher level of trust. In thiscase, the first and second trust levels may be averaged to create thecombined trust level, which would then also be a value on a scale of 0to 1. However, various techniques and data ranges may be used toimplement the trust levels, so various techniques may be used to combinethe different trust levels to create a combined trust level.

At 312, a determination is made as to whether the combined trust levelmeets the designated trust threshold value. The determination may bemade by comparing the trust level with the designated trust thresholdvalue.

If the combined trust level does meet the designated trust thresholdvalue, then at 314 an indication that the website is trusted isprovided. In some embodiments, an indication of the trustworthiness ofthe website may be transmitted to a user associated with the creation ormaintenance of the website. Additionally, or alternately, the websitemay be permitted to post a notification such as a seal or iconindicating that the website has been analyzed and deemed trustworthy.

If instead the combined trust level does not meet the designated trustthreshold value, then at 314 an indication that the website is nottrusted is provided. Regardless of the outcome of the determination at312, the determination as to whether the website is trusted may bestored on a storage device associated with the website hosting system.

In some embodiments, a website that is determined to be untrustworthymay be subjected to further analysis. For instance, a user may visit thewebsite to review its contents, an administrator may review the sourcecode used to create the website, or the website may be sent to anexternal service for further testing.

If the website is deemed malicious, then the website may be removed fromthe server so that it does not perform any further malicious action. Insome embodiments, a website may be removed automatically after thewebsite fails to meet a designated trust threshold value. Alternately,an administrator may decide to remove the website after reviewing theresults of automated tools and any other information concerning thewebsite.

In some embodiments, whether a website is removed automatically after itis deemed malicious may depend on the type of malicious behaviordetected or the difference between the combined trust level and thedesignated trust threshold value. For instance, if a website is detectedas performing clearly malicious actions such as distributing softwareknown to be malicious, then the website may be removed automatically. Asanother example, a website may be removed automatically if its combinedtrust level is far below the designated trust threshold value.

FIG. 4 shows a flow diagram of a method 400 for determining trust inlanguage translation, performed in accordance with one embodiment. Insome embodiments, structured or formatted documents such as webpages mayneed to be transformed for presentation. For example, a webpage may needto be translated from one written language to another written language.As another example, the content of a webpage may require editing. Thetransformation can include any operations related to changing thecontent of the document.

In some embodiments, the webpage may be sent to an external service fortransformation. The external services may include any services notcontrolled or not fully trusted by the owner of the webpage or otherstructured document. For example, the webpage may be sent to a firstexternal service for editing and sent to a second external service fortranslation from one language to another language.

In some implementations, written language translation or other semantictransformation may occur after content has been processed into a formatthat included both content and control elements. For example, the formatmay be a webpage that includes both written language and HTML. Someformats like HTML include active code elements with the control portionsthat are not visible apparent but can potentially perform maliciousactions.

If a resource is transmitted to an untrusted party for translation, theuntrusted party can perform malicious alteration of the invisiblecontrol portions along with the language translations. These changescould then perform arbitrary malicious actions after inclusion of theresource into a larger software system or web site. In a first example,the external service may alter the webpage to include a link to amalicious file such as a virus, Trojan, worm, or other malicioussoftware program. In a second example, the external service may alterthe webpage to include a form designed to receive confidentialinformation from users and pass the information to a malicious party. Ina third example, the external service may insert into the webpagemalicious code that redirects a web browser to another malicious webpagesuch as a webpage controlled by the external service. In a fourthexample, the external service may insert into the webpage malicious codethat attempts to retrieve private information from a web browser such asbrowsing history, login status of other websites, or stored usernamesand passwords. In a fifth example, the external service may insert intothe webpage malicious code that attempts to directly exploit weaknessesin a client web browser. In a sixth example, the external service mayinsert into the webpage malicious code that attempts to directly exploitweaknesses in software, such as a plug-in, installed in a client webbrowser.

In some implementations, the method 400 may be used to determine trustin a transformed structured document even in cases where little is knownabout the structured document and/or the transformation performed by theexternal service. In some instances, the service provider or webpageauthor may know relatively little about the structured document sent tothe external services. For example, the service provider may not knowhow the structured document was created or whether the structureddocument is well-formed or free of errors. In some instances, theservice provider or webpage author may know relatively little about thetransformation performed by the external service. For example, theexternal service may or may not transform HTML hovertext, URIs,alternate text for images or other media, or other portions of thestructured documents.

The method 400 shown in FIG. 4 may be used to determine whether awebpage, or any other structured resource having data and metadata, mayhave been maliciously altered during a transformation. Thetransformation may include translation of a written language, semanticmanipulation, or any other type of data transformation altering thewebpage. The translation may be performed by an untrusted or partiallytrusted party.

At 402, a request to translate a webpage is received. In someembodiments, the request may be received at a computing device. Thecomputing device may be associated with the web hosting service provideror with an owner of the webpage. The computing device may be used toanalyze webpages hosted at the hosting provider.

In some embodiments, the request to evaluate the webpage may be receivedas part of an automatic procedure. For example, the hosting provider mayautomatically translate a webpage or group of webpages into anotherlanguage. As another example, the website owner may automatically submita webpage or group of webpages to an external service for editing.

In some embodiments, the request to translate the webpage may begenerated based on a detected or automated event. For example, a webpagemay be automatically translated when it is created, when a designatedtime has elapsed since the creation of the webpage, when a designatedtraffic threshold for the webpage has been surpassed, or when any otherdesignated event is detected.

In some embodiments, the webpage may be a primarily static webpage inwhich the content of the webpage is hard coded into the controlsequences. Alternately, or additionally, the webpage may include dynamicportions.

At 404, first metadata for the webpage is identified. The first metadatamay be identified by analyzing a formatted webpage or other structureddocument. A webpage or other structured document may be logicallydivided into a content portion and a control portion. The contentportion may include the information displayed by the webpage, while thecontrol portion may include style or formatting information, links,forms for submitting information to a server, scripting languageinstructions, and other control sequences. In some embodiments, thetranslation or transformation of the webpage may be expected to changeonly or primarily the content of the webpage, not the control sequences.The control sequences can include HTML, XML, JavaScript®, or othermarkup tags in the webpage.

In some embodiments, the metadata may be determined by analyzing thewebpage, including the control sequences. The metadata to use forcomparison may be strategically determined based on the type ofdocuments that are being compared, the type of control sequencesincluded in the documents, and a desired degree of security or trust.

For example, the metadata can include counts of different controlsequences, numbers of key attributes, attribute values, or any other keystatistics or control sequence information. The metadata may include anindication tags in the website that may be easily abused, such as theHTML onclick attribute tag. The metadata may include an indication oflinks to websites other than websites controlled by the website owner.The metadata may include an indication of links to websites other thanthe website itself. The metadata may include an indication of domainslinked to by the website that are not controlled by the website owner.The metadata may include an indication of the content of script tags.The metadata may include selective checksums of portions of the webpage.For example, the metadata may include a checksum of the website afterthe website is stripped of content. The metadata may include anExtensible Stylesheet Language Transformations (XLST) and/or ExtensibleMarkup Language (XML) signature.

In some embodiments, the metadata values may be recorded as unalteredvalues, as checksum values, as encrypted values, as hashed values, or inany other way. The type and results of the analysis may be stored asmetadata. The metadata may be stored along with a unique identifier forthe page.

At 406, the first metadata for the webpage is stored. In someembodiments, the metadata may be stored at a storage device accessibleto the website creator or the website hosting provider. For example, themetadata may be stored in a database, in a content management system(CMS), or in some other storage location.

In some embodiments, the metadata may be encrypted or hashed andtransmitted with the webpage. In this case, the metadata may beencrypted using a symmetric key stored at the server, an identifierassociated with the webpage (e.g., a URI), and/or a salt value.Techniques for transmitting encrypted information with a communicationto a possibly untrusted source are discussed in greater detail inco-pending and commonly assigned U.S. patent application Ser. No.13/005,073 by Dapkus et al., titled “Secure Communications,” filed Jan.11, 2011, which is incorporated herein by reference in its entirety andfor all purposes.

At 408, the webpage is transmitted to a translation service. In someembodiments, the translation service may be an external service that isnot controlled by the webpage author, the webpage web hosting provider,or another trusted party. Thus, the translation service may not be fullytrusted.

In some embodiments, the untranslated webpage may be transmitted to thetranslation service in an individual message. Alternately, theuntranslated webpage may be transmitted to in a combined message withother untranslated webpages.

In some embodiments, the translation service may perform anymodification of the data in the webpage or resource transmitted to thetranslation service. For example, the translation service may translatewritten language in the webpage written in a first language to writtenlanguage in a second language. As another example, the translationservice may edit, proof, or otherwise alter written language in a firstlanguage. As yet another example, the translation service may insertmaterial such as advertisements. As long as the translation service isnot expected to perform a modification or transformation of the resourcethat significantly alters the metadata used to verify that themodification was not malicious, any sort of modification ortransformation may be performed by the translation service.

At 410, the translated webpage is received from the translation service.In some embodiments, the translated webpage may be received from thetranslation service in an individual message. Alternately, thetranslated webpage may be received in a combined message with othertranslated webpages.

At 412, second metadata is identified for the translated webpage. Asimilar analysis may be performed on the translated webpage so that thesame types of metadata identified for the untranslated webpage areidentified for the translated webpage. In some embodiments, theprocedure for identifying the second metadata may be substantiallysimilar to the procedure for identifying the first metadata at 404.

At 414, a determination is made as to whether the first metadata matchesthe second metadata. In some embodiments, the first and second metadatamay need to be an exact match for the determination at 414 to yield amatch. Alternately, a relatively minor mismatch between the two sets ofmetadata may not trigger a mismatch. The degree of similarity requiredbetween the first and second metadata and the procedure for comparingthe first and second metadata may be strategically determined based onthe type of metadata being compared, the security requirements for thetranslated webpage, the trust afforded to the translation service, andany other factors.

If the first metadata was encrypted or hashed, then the metadata mayneed to be re-hashed or decrypted when the translated webpage isreceived, in order to facilitate making a comparison. If instead thefirst metadata was stored in a storage device, then the stored metadatamay be retrieved when the translated webpage is received.

At 416, an indication that the translation is not trusted may beprovided. The indication that the translation is not trusted may betransmitted in a message, stored on a storage device, or conveyed in anyother way.

In some embodiments, the indication that the translation is not trustedmay be transmitted to a user such as an administrator. The indicationmay specify differences between the two sets of metadata. Theadministrator may review the translated webpage and/or the differencesbetween the two sets of metadata and determine whether to take furtheraction.

If instead the first and second metadata match, then at 418 anindication is provided that the translation is trusted. Regardless ofthe outcome of the determination made at 414, the indication provided at416 or 418 may be stored on a storage device, transmitted in a message,recorded in a log, or provided in any other way.

FIG. 5A shows a system diagram 500 illustrating architectural componentsof an on-demand service environment, in accordance with one embodiment.

A client machine located in the cloud 504 (or Internet) may communicatewith the on-demand service environment via one or more edge routers 508and 512. The edge routers may communicate with one or more core switches520 and 524 via firewall 516. The core switches may communicate with aload balancer 528, which may distribute server load over different pods,such as the pods 540 and 544. The pods 540 and 544, which may eachinclude one or more servers and/or other computing resources, mayperform data processing and other operations used to provide on-demandservices. Communication with the pods may be conducted via pod switches532 and 536. Components of the on-demand service environment maycommunicate with a database storage system 556 via a database firewall548 and a database switch 552.

As shown in FIGS. 5A and 5B, accessing an on-demand service environmentmay involve communications transmitted among a variety of differenthardware and/or software components. Further, the on-demand serviceenvironment 500 is a simplified representation of an actual on-demandservice environment. For example, while only one or two devices of eachtype are shown in FIGS. 5A and 5B, some embodiments of an on-demandservice environment may include anywhere from one to many devices ofeach type. Also, the on-demand service environment need not include eachdevice shown in FIGS. 5A and 5B, or may include additional devices notshown in FIGS. 5A and 5B.

Moreover, one or more of the devices in the on-demand serviceenvironment 500 may be implemented on the same physical device or ondifferent hardware. Some devices may be implemented using hardware or acombination of hardware and software. Thus, terms such as “dataprocessing apparatus,” “machine,” “server” and “device” as used hereinare not limited to a single hardware device, but rather include anyhardware and software configured to provide the described functionality.

The cloud 504 is intended to refer to a data network or plurality ofdata networks, often including the Internet. Client machines located inthe cloud 504 may communicate with the on-demand service environment toaccess services provided by the on-demand service environment. Forexample, client machines may access the on-demand service environment toretrieve, store, edit, and/or process information.

In some embodiments, the edge routers 508 and 512 route packets betweenthe cloud 504 and other components of the on-demand service environment500. The edge routers 508 and 512 may employ the Border Gateway Protocol(BGP). The BGP is the core routing protocol of the Internet. The edgerouters 508 and 512 may maintain a table of IP networks or ‘prefixes’which designate network reachability among autonomous systems on theInternet.

In one or more embodiments, the firewall 516 may protect the innercomponents of the on-demand service environment 500 from Internettraffic. The firewall 516 may block, permit, or deny access to the innercomponents of the on-demand service environment 500 based upon a set ofrules and other criteria. The firewall 516 may act as one or more of apacket filter, an application gateway, a stateful filter, a proxyserver, or any other type of firewall.

In some embodiments, the core switches 520 and 524 are high-capacityswitches that transfer packets within the on-demand service environment500. The core switches 520 and 524 may be configured as network bridgesthat quickly route data between different components within theon-demand service environment. In some embodiments, the use of two ormore core switches 520 and 524 may provide redundancy and/or reducedlatency.

In some embodiments, the pods 540 and 544 may perform the core dataprocessing and service functions provided by the on-demand serviceenvironment. Each pod may include various types of hardware and/orsoftware computing resources. An example of the pod architecture isdiscussed in greater detail with reference to FIG. 5B.

In some embodiments, communication between the pods 540 and 544 may beconducted via the pod switches 532 and 536. The pod switches 532 and 536may facilitate communication between the pods 540 and 544 and clientmachines located in the cloud 504, for example via core switches 520 and524. Also, the pod switches 532 and 536 may facilitate communicationbetween the pods 540 and 544 and the database storage 556.

In some embodiments, the load balancer 528 may distribute workloadbetween the pods 540 and 544. Balancing the on-demand service requestsbetween the pods may assist in improving the use of resources,increasing throughput, reducing response times, and/or reducingoverhead. The load balancer 528 may include multilayer switches toanalyze and forward traffic.

In some embodiments, access to the database storage 556 may be guardedby a database firewall 548. The database firewall 548 may act as acomputer application firewall operating at the database applicationlayer of a protocol stack. The database firewall 548 may protect thedatabase storage 556 from application attacks such as structure querylanguage (SQL) injection, database rootkits, and unauthorizedinformation disclosure.

In some embodiments, the database firewall 548 may include a host usingone or more forms of reverse proxy services to proxy traffic beforepassing it to a gateway router. The database firewall 548 may inspectthe contents of database traffic and block certain content or databaserequests. The database firewall 548 may work on the SQL applicationlevel atop the TCP/IP stack, managing applications' connection to thedatabase or SQL management interfaces as well as intercepting andenforcing packets traveling to or from a database network or applicationinterface.

In some embodiments, communication with the database storage system 556may be conducted via the database switch 552. The multi-tenant databasesystem 556 may include more than one hardware and/or software componentsfor handling database queries. Accordingly, the database switch 552 maydirect database queries transmitted by other components of the on-demandservice environment (e.g., the pods 540 and 544) to the correctcomponents within the database storage system 556.

In some embodiments, the database storage system 556 is an on-demanddatabase system shared by many different organizations. The on-demanddatabase system may employ a multi-tenant approach, a virtualizedapproach, or any other type of database approach. An on-demand databasesystem is discussed in greater detail with reference to FIGS. 6 and 7.

FIG. 5B shows a system diagram illustrating the architecture of the pod544, in accordance with one embodiment. The pod 544 may be used torender services to a user of the on-demand service environment 500.

In some embodiments, each pod may include a variety of servers and/orother systems. The pod 544 includes one or more content batch servers564, content search servers 568, query servers 572, file force servers576, access control system (ACS) servers 580, batch servers 584, and appservers 588. Also, the pod 544 includes database instances 590, quickfile systems (QFS) 592, and indexers 594. In one or more embodiments,some or all communication between the servers in the pod 544 may betransmitted via the switch 536.

In some embodiments, the application servers 588 may include a hardwareand/or software framework dedicated to the execution of procedures(e.g., programs, routines, scripts) for supporting the construction ofapplications provided by the on-demand service environment 500 via thepod 544. Some such procedures may include operations for providing theservices described herein.

The content batch servers 564 may requests internal to the pod. Theserequests may be long-running and/or not tied to a particular customer.For example, the content batch servers 564 may handle requests relatedto log mining, cleanup work, and maintenance tasks.

The content search servers 568 may provide query and indexer functions.For example, the functions provided by the content search servers 568may allow users to search through content stored in the on-demandservice environment.

The Fileforce servers 576 may manage requests information stored in theFileforce storage 578. The Fileforce storage 578 may store informationsuch as documents, images, and basic large objects (BLOBs). By managingrequests for information using the Fileforce servers 576, the imagefootprint on the database may be reduced.

The query servers 572 may be used to retrieve information from one ormore file systems. For example, the query system 572 may receiverequests for information from the app servers 588 and then transmitinformation queries to the NFS 596 located outside the pod.

The pod 544 may share a database instance 590 configured as amulti-tenant environment in which different organizations share accessto the same database. Additionally, services rendered by the pod 544 mayrequire various hardware and/or software resources. In some embodiments,the ACS servers 580 may control access to data, hardware resources, orsoftware resources.

In some embodiments, the batch servers 584 may process batch jobs, whichare used to run tasks at specified times. Thus, the batch servers 584may transmit instructions to other servers, such as the app servers 588,to trigger the batch jobs.

In some embodiments, the QFS 592 may be an open source file systemavailable from Sun Microsystems® of Santa Clara, Calif. The QFS mayserve as a rapid-access file system for storing and accessinginformation available within the pod 544. The QFS 592 may support somevolume management capabilities, allowing many disks to be groupedtogether into a file system. File system metadata can be kept on aseparate set of disks, which may be useful for streaming applicationswhere long disk seeks cannot be tolerated. Thus, the QFS system maycommunicate with one or more content search servers 568 and/or indexers594 to identify, retrieve, move, and/or update data stored in thenetwork file systems 596 and/or other storage systems.

In some embodiments, one or more query servers 572 may communicate withthe NFS 596 to retrieve and/or update information stored outside of thepod 544. The NFS 596 may allow servers located in the pod 544 to accessinformation to access files over a network in a manner similar to howlocal storage is accessed.

In some embodiments, queries from the query servers 522 may betransmitted to the NFS 596 via the load balancer 520, which maydistribute resource requests over various resources available in theon-demand service environment. The NFS 596 may also communicate with theQFS 592 to update the information stored on the NFS 596 and/or toprovide information to the QFS 592 for use by servers located within thepod 544.

In some embodiments, the pod may include one or more database instances590. The database instance 590 may transmit information to the QFS 592.When information is transmitted to the QFS, it may be available for useby servers within the pod 544 without requiring an additional databasecall.

In some embodiments, database information may be transmitted to theindexer 594. Indexer 594 may provide an index of information availablein the database 590 and/or QFS 592. The index information may beprovided to file force servers 576 and/or the QFS 592.

FIG. 6 shows a block diagram of an environment 610 wherein an on-demanddatabase service might be used, in accordance with one embodiment.

Environment 610 includes an on-demand database service 616. User system612 may be any machine or system that is used by a user to access adatabase user system. For example, any of user systems 612 can be ahandheld computing device, a mobile phone, a laptop computer, a workstation, and/or a network of computing devices. As illustrated in FIGS.6 and 7, user systems 612 might interact via a network 614 with theon-demand database service 616.

An on-demand database service, such as system 616, is a database systemthat is made available to outside users that do not need to necessarilybe concerned with building and/or maintaining the database system, butinstead may be available for their use when the users need the databasesystem (e.g., on the demand of the users). Some on-demand databaseservices may store information from one or more tenants stored intotables of a common database image to form a multi-tenant database system(MTS).

Accordingly, “on-demand database service 616” and “system 616” will beused interchangeably herein. A database image may include one or moredatabase objects. A relational database management system (RDBMS) or theequivalent may execute storage and retrieval of information against thedatabase object(s). Application platform 618 may be a framework thatallows the applications of system 616 to run, such as the hardwareand/or software, e.g., the operating system. In an embodiment, on-demanddatabase service 616 may include an application platform 618 thatenables creation, managing and executing one or more applicationsdeveloped by the provider of the on-demand database service, usersaccessing the on-demand database service via user systems 612, or thirdparty application developers accessing the on-demand database servicevia user systems 612.

One arrangement for elements of system 616 is shown in FIG. 6, includinga network interface 620, application platform 618, tenant data storage622 for tenant data 623, system data storage 624 for system data 625accessible to system 616 and possibly multiple tenants, program code 626for implementing various functions of system 616, and a process space628 for executing MTS system processes and tenant-specific processes,such as running applications as part of an application hosting service.Additional processes that may execute on system 616 include databaseindexing processes.

The users of user systems 612 may differ in their respective capacities,and the capacity of a particular user system 612 might be entirelydetermined by permissions (permission levels) for the current user. Forexample, where a call center agent is using a particular user system 612to interact with system 616, the user system 612 has the capacitiesallotted to that call center agent. However, while an administrator isusing that user system to interact with system 616, that user system hasthe capacities allotted to that administrator. In systems with ahierarchical role model, users at one permission level may have accessto applications, data, and database information accessible by a lowerpermission level user, but may not have access to certain applications,database information, and data accessible by a user at a higherpermission level. Thus, different users may have different capabilitieswith regard to accessing and modifying application and databaseinformation, depending on a user's security or permission level.

Network 614 is any network or combination of networks of devices thatcommunicate with one another. For example, network 614 can be any one orany combination of a LAN (local area network), WAN (wide area network),telephone network, wireless network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. As the most common type of computer network in currentuse is a TCP/IP (Transfer Control Protocol and Internet Protocol)network (e.g., the Internet), that network will be used in many of theexamples herein. However, it should be understood that the networks usedin some embodiments are not so limited, although TCP/IP is a frequentlyimplemented protocol.

User systems 612 might communicate with system 616 using TCP/IP and, ata higher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, user system 612 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP messages to and from anHTTP server at system 616. Such an HTTP server might be implemented asthe sole network interface between system 616 and network 614, but othertechniques might be used as well or instead. In some implementations,the interface between system 616 and network 614 includes load sharingfunctionality, such as round-robin HTTP request distributors to balanceloads and distribute incoming HTTP requests evenly over a plurality ofservers. At least as for the users that are accessing that server, eachof the plurality of servers has access to the MTS' data; however, otheralternative configurations may be used instead.

In one embodiment, system 616, shown in FIG. 6, implements a web-basedcustomer relationship management (CRM) system. For example, in oneembodiment, system 616 includes application servers configured toimplement and execute CRM software applications as well as providerelated data, code, forms, webpages and other information to and fromuser systems 612 and to store to, and retrieve from, a database systemrelated data, objects, and Webpage content. With a multi-tenant system,data for multiple tenants may be stored in the same physical databaseobject, however, tenant data typically is arranged so that data of onetenant is kept logically separate from that of other tenants so that onetenant does not have access to another tenant's data, unless such datais expressly shared. In certain embodiments, system 616 implementsapplications other than, or in addition to, a CRM application. Forexample, system 616 may provide tenant access to multiple hosted(standard and custom) applications. User (or third party developer)applications, which may or may not include CRM, may be supported by theapplication platform 618, which manages creation, storage of theapplications into one or more database objects and executing of theapplications in a virtual machine in the process space of the system616.

Each user system 612 could include a desktop personal computer,workstation, laptop, PDA, cell phone, or any wireless access protocol(WAP) enabled device or any other computing device capable ofinterfacing directly or indirectly to the Internet or other networkconnection. User system 612 typically runs an HTTP client, e.g., abrowsing program, such as Microsoft's Internet Explorer® browser,Mozilla's Firefox® browser, Opera's browser, or a WAP-enabled browser inthe case of a cell phone, PDA or other wireless device, or the like,allowing a user (e.g., subscriber of the multi-tenant database system)of user system 612 to access, process and view information, pages andapplications available to it from system 616 over network 614.

Each user system 612 also typically includes one or more user interfacedevices, such as a keyboard, a mouse, trackball, touch pad, touchscreen, pen or the like, for interacting with a graphical user interface(GUI) provided by the browser on a display (e.g., a monitor screen, LCDdisplay, etc.) in conjunction with pages, forms, applications and otherinformation provided by system 616 or other systems or servers. Forexample, the user interface device can be used to access data andapplications hosted by system 616, and to perform searches on storeddata, and otherwise allow a user to interact with various GUI pages thatmay be presented to a user. As discussed above, embodiments are suitablefor use with the Internet, which refers to a specific globalinternetwork of networks. However, it should be understood that othernetworks can be used instead of the Internet, such as an intranet, anextranet, a virtual private network (VPN), a non-TCP/IP based network,any LAN or WAN or the like.

According to one embodiment, each user system 612 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium® processor or the like. Similarly, system 616(and additional instances of an MTS, where more than one is present) andall of their components might be operator configurable usingapplication(s) including computer code to run using a central processingunit such as processor system 617, which may include an Intel Pentium®processor or the like, and/or multiple processor units.

A computer program product embodiment includes a machine-readablestorage medium (media) having instructions stored thereon/in which canbe used to program a computer to perform any of the processes of theembodiments described herein. Computer code for operating andconfiguring system 616 to intercommunicate and to process webpages,applications and other data and media content as described herein arepreferably downloaded and stored on a hard disk, but the entire programcode, or portions thereof, may also be stored in any other volatile ornon-volatile memory medium or device, such as a ROM or RAM, or providedon any media capable of storing program code, such as any type ofrotating media including floppy disks, optical discs, digital versatiledisk (DVD), compact disk (CD), microdrive, and magneto-optical disks,and magnetic or optical cards, nanosystems (including molecular memoryICs), or any type of media or device suitable for storing instructionsand/or data. Additionally, the entire program code, or portions thereof,may be transmitted and downloaded from a software source over atransmission medium, e.g., over the Internet, or from another server, ortransmitted over any other conventional network connection (e.g.,extranet, VPN, LAN, etc.) using any communication medium and protocols(e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.). It will also be appreciatedthat computer code for implementing embodiments can be implemented inany programming language that can be executed on a client system and/orserver or server system such as, for example, C, C++, HTML, any othermarkup language, Java™, JavaScript®, ActiveX®, any other scriptinglanguage, such as VBScript, and many other programming languages as arewell known may be used. (Java™ is a trademark of Sun Microsystems®,Inc.).

According to one embodiment, each system 616 is configured to providewebpages, forms, applications, data and media content to user (client)systems 612 to support the access by user systems 612 as tenants ofsystem 616. As such, system 616 provides security mechanisms to keepeach tenant's data separate unless the data is shared. If more than oneMTS is used, they may be located in close proximity to one another(e.g., in a server farm located in a single building or campus), or theymay be distributed at locations remote from one another (e.g., one ormore servers located in city A and one or more servers located in cityB). As used herein, each MTS could include logically and/or physicallyconnected servers distributed locally or across one or more geographiclocations. Additionally, the term “server” is meant to include acomputer system, including processing hardware and process space(s), andan associated storage system and database application (e.g., OODBMS orRDBMS) as is well known in the art.

It should also be understood that “server system” and “server” are oftenused interchangeably herein. Similarly, the database object describedherein can be implemented as single databases, a distributed database, acollection of distributed databases, a database with redundant online oroffline backups or other redundancies, etc., and might include adistributed database or storage network and associated processingintelligence.

FIG. 7 also shows a block diagram of environment 610 furtherillustrating system 616 and various interconnections, in accordance withone embodiment. FIG. 7 shows that user system 612 may include processorsystem 612A, memory system 612B, input system 612C, and output system612D. FIG. 7 shows network 614 and system 616. FIG. 7 also shows thatsystem 616 may include tenant data storage 622, tenant data 623, systemdata storage 624, system data 625, User Interface (UI) 730, ApplicationProgram Interface (API) 732, PL/SOQL 734, save routines 736, applicationsetup mechanism 738, applications servers 7001-700N, system processspace 702, tenant process spaces 704, tenant management process space710, tenant storage area 712, user storage 714, and application metadata716. In other embodiments, environment 610 may not have the sameelements as those listed above and/or may have other elements insteadof, or in addition to, those listed above.

User system 612, network 614, system 616, tenant data storage 622, andsystem data storage 624 were discussed above in FIG. 6. Regarding usersystem 612, processor system 612A may be any combination of processors.Memory system 612B may be any combination of one or more memory devices,short term, and/or long term memory. Input system 612C may be anycombination of input devices, such as keyboards, mice, trackballs,scanners, cameras, and/or interfaces to networks. Output system 612D maybe any combination of output devices, such as monitors, printers, and/orinterfaces to networks. As shown by FIG. 7, system 616 may include anetwork interface 620 (of FIG. 6) implemented as a set of HTTPapplication servers 700, an application platform 618, tenant datastorage 622, and system data storage 624. Also shown is system processspace 702, including individual tenant process spaces 704 and a tenantmanagement process space 710. Each application server 700 may beconfigured to tenant data storage 622 and the tenant data 623 therein,and system data storage 624 and the system data 625 therein to serverequests of user systems 612. The tenant data 623 might be divided intoindividual tenant storage areas 712, which can be either a physicalarrangement and/or a logical arrangement of data. Within each tenantstorage area 712, user storage 714 and application metadata 716 might besimilarly allocated for each user. For example, a copy of a user's mostrecently used (MRU) items might be stored to user storage 714.Similarly, a copy of MRU items for an entire organization that is atenant might be stored to tenant storage area 712. A UI 730 provides auser interface and an API 732 provides an application programmerinterface to system 616 resident processes to users and/or developers atuser systems 612. The tenant data and the system data may be stored invarious databases, such as Oracle™ databases.

Application platform 618 includes an application setup mechanism 738that supports application developers' creation and management ofapplications, which may be saved as metadata into tenant data storage622 by save routines 736 for execution by subscribers as tenant processspaces 704 managed by tenant management process 710 for example.Invocations to such applications may be coded using PL/SOQL 34 thatprovides a programming language style interface extension to API 732. Adetailed description of some PL/SOQL language embodiments is discussedin commonly assigned U.S. Pat. No. 7,730,478, titled METHOD AND SYSTEMFOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANTON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep. 21, 2007,which is hereby incorporated by reference in its entirety and for allpurposes. Invocations to applications may be detected by systemprocesses, which manage retrieving application metadata 716 for thesubscriber making the invocation and executing the metadata as anapplication in a virtual machine.

Each application server 700 may be communicably coupled to databasesystems, e.g., having access to system data 625 and tenant data 623, viaa different network connection. For example, one application server 7001might be coupled via the network 614 (e.g., the Internet), anotherapplication server 700N-1 might be coupled via a direct network link,and another application server 700N might be coupled by yet a differentnetwork connection. Transfer Control Protocol and Internet Protocol(TCP/IP) are typical protocols for communicating between applicationservers 700 and the database system. However, other transport protocolsmay be used to optimize the system depending on the network interconnectused.

In certain embodiments, each application server 700 is configured tohandle requests for any user associated with any organization that is atenant. Because it is desirable to be able to add and remove applicationservers from the server pool at any time for any reason, there ispreferably no server affinity for a user and/or organization to aspecific application server 700. In one embodiment, therefore, aninterface system implementing a load balancing function (e.g., an F5Big-IP load balancer) is communicably coupled between the applicationservers 700 and the user systems 612 to distribute requests to theapplication servers 700. In one embodiment, the load balancer uses aleast connections algorithm to route user requests to the applicationservers 700. Other examples of load balancing algorithms, such as roundrobin and observed response time, also can be used. For example, incertain embodiments, three consecutive requests from the same user couldhit three different application servers 700, and three requests fromdifferent users could hit the same application server 700. In thismanner, system 616 is multi-tenant, wherein system 616 handles storageof, and access to, different objects, data and applications acrossdisparate users and organizations.

As an example of storage, one tenant might be a company that employs asales force where each call center agent uses system 616 to manage theirsales process. Thus, a user might maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (e.g., intenant data storage 622). In an example of a MTS arrangement, since allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem having nothing more than network access, the user can manage hisor her sales efforts and cycles from any of many different user systems.For example, if a call center agent is visiting a customer and thecustomer has Internet access in their lobby, the call center agent canobtain critical updates as to that customer while waiting for thecustomer to arrive in the lobby.

While each user's data might be separate from other users' dataregardless of the employers of each user, some data might beorganization-wide data shared or accessible by a plurality of users orall of the users for a given organization that is a tenant. Thus, theremight be some data structures managed by system 616 that are allocatedat the tenant level while other data structures might be managed at theuser level. Because an MTS might support multiple tenants includingpossible competitors, the MTS should have security protocols that keepdata, applications, and application use separate. Also, because manytenants may opt for access to an MTS rather than maintain their ownsystem, redundancy, up-time, and backup are additional functions thatmay be implemented in the MTS. In addition to user-specific data andtenant specific data, system 616 might also maintain system level datausable by multiple tenants or other data. Such system level data mightinclude industry reports, news, postings, and the like that are sharableamong tenants.

In certain embodiments, user systems 612 (which may be clientmachines/systems) communicate with application servers 700 to requestand update system-level and tenant-level data from system 616 that mayrequire sending one or more queries to tenant data storage 622 and/orsystem data storage 624. System 616 (e.g., an application server 700 insystem 616) automatically generates one or more SQL statements (e.g.,SQL queries) that are designed to access the desired information. Systemdata storage 624 may generate query plans to access the requested datafrom the database.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefinedcategories. A “table” is one representation of a data object, and may beused herein to simplify the conceptual description of objects and customobjects according to some embodiments. It should be understood that“table” and “object” may be used interchangeably herein. Each tablegenerally contains one or more data categories logically arranged ascolumns or fields in a viewable schema. Each row or record of a tablecontains an instance of data for each category defined by the fields.For example, a CRM database may include a table that describes acustomer with fields for basic contact information such as name,address, phone number, fax number, etc. Another table might describe apurchase order, including fields for information such as customer,product, sale price, date, etc. In some multi-tenant database systems,standard entity tables might be provided for use by all tenants. For CRMdatabase applications, such standard entities might include tables foraccount, contact, lead, and opportunity data, each containingpre-defined fields. It should be understood that the word “entity” mayalso be used interchangeably herein with “object” and “table”.

In some multi-tenant database systems, tenants may be allowed to createand store custom objects, or they may be allowed to customize standardentities or objects, for example by creating custom fields for standardobjects, including custom index fields. U.S. Pat. No. 7,779,039, titledCUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM, byWeissman, et al., and which is hereby incorporated by reference in itsentirety and for all purposes, teaches systems and methods for creatingcustom objects as well as customizing standard objects in a multi-tenantdatabase system. In some embodiments, for example, all custom entitydata rows are stored in a single multi-tenant physical table, which maycontain multiple logical tables per organization. In some embodiments,multiple “tables” for a single customer may actually be stored in onelarge table and/or in the same table as the data of other customers.

These and other aspects of the disclosure may be implemented by varioustypes of hardware, software, firmware, etc. For example, some featuresof the disclosure may be implemented, at least in part, bymachine-readable media that include program instructions, stateinformation, etc., for performing various operations described herein.Examples of program instructions include both machine code, such asproduced by a compiler, and files containing higher-level code that maybe executed by the computer using an interpreter. Examples ofmachine-readable media include, but are not limited to, magnetic mediasuch as hard disks, floppy disks, and magnetic tape; optical media suchas CD-ROM disks; magneto-optical media; and hardware devices that arespecially configured to store and perform program instructions, such asread-only memory devices (“ROM”) and random access memory (“RAM”).

While one or more implementations and techniques are described withreference to an embodiment in which a service cloud console isimplemented in a system having an application server providing a frontend for an on-demand database service capable of supporting multipletenants, the one or more implementations and techniques are not limitedto multi-tenant databases nor deployment on application servers.Embodiments may be practiced using other database architectures, i.e.,ORACLE®, DB2®, by IBM and the like without departing from the scope ofthe embodiments claimed.

Any of the above embodiments may be used alone or together with oneanother in any combination. Although various embodiments may have beenmotivated by various deficiencies with the prior art, which may bediscussed or alluded to in one or more places in the specification, theembodiments do not necessarily address any of these deficiencies. Inother words, different embodiments may address different deficienciesthat may be discussed in the specification. Some embodiments may onlypartially address some deficiencies or just one deficiency that may bediscussed in the specification, and some embodiments may not address anyof these deficiencies.

While various embodiments have been described herein, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of the present applicationshould not be limited by any of the embodiments described herein, butshould be defined only in accordance with the following andlater-submitted claims and their equivalents.

What is claimed is:
 1. A method of determining a confidentiality for asite record, the method comprising: identifying, at a computing device,a site record for analysis; identifying a source for the site record;determining, based on the source, a source-based confidentiality for thesite record; identifying, based on the site record, a designatedconfidentiality for the site record; determining that the designatedconfidentiality is different from the source-based confidentiality; andresponsive to the determination that the designated confidentiality isdifferent from the source-based confidentiality, storing thesource-based confidentiality for the site record on a storage medium. 2.The method of claim 1, wherein determining the source-basedconfidentiality comprises: accessing a list of designatedconfidentiality levels, each associated with a respective one of aplurality of site record sources.
 3. The method of claim 1, whereindetermining the source-based confidentiality comprises: determining asource type of the source; and identifying a confidentiality level basedon the source type.
 4. The method of claim 3, wherein the source typeindicates whether the source is internal or external to an on-demandservices environment.
 5. The method of claim 3, wherein the source typeindicates whether the source is accessible to an entity accessing anon-demand services environment.
 6. The method of claim 1, wherein thesource-based confidentiality is determined based at least in part onpublic accessibility of the source of the site record.
 7. The method ofclaim 1, wherein the source-based confidentiality is determined based atleast in part on a trust level of the source, the trust level indicatinga degree to which the source is trusted in an on-demand servicesenvironment.
 8. The method of claim 1, wherein the designatedconfidentiality is determined based on identifying confidentialinformation included in the site record.
 9. The method of claim 1,wherein the designated confidentiality has a default or initial level.10. The method of claim 1, further comprising: storing contextualinformation for the site record, the contextual information includingone or both of: the source, and a time at which determination of thesource-based confidentiality was last conducted.
 11. The method of claim1, wherein the site record is associated with a network address.
 12. Themethod of claim 1, wherein the site record is associated with a siteaccessible via an on-demand services environment, the site being one of:a computer system, a program, a configuration, a web site, or acomputing services construct.
 13. The method of claim 1, wherein thesource of the site record is one of: a server log, an audit trail,information internal to an on-demand services environment, an Internetsearch engine, an Internet spider cache, a public network, aninformation cache or repository, or a communication received by anentity of an on-demand services environment.
 14. One or more servers fordetermining a confidentiality for a site record, the one or more serverscomprising: one or more processors operable to cause one or moreinstructions to be executed to: identify, at a computing device, a siterecord for analysis; identify a source for the site record; determine,based on the source, a source-based confidentiality for the site record;identify, based on the site record, a designated confidentiality for thesite record; determine that the designated confidentiality is differentfrom the source-based confidentiality; and responsive to thedetermination that the designated confidentiality is different from thesource-based confidentiality, store the source-based confidentiality forthe site record on a storage medium.
 15. The one or more servers ofclaim 14, wherein determining the source-based confidentialitycomprises: accessing a list of designated confidentiality levels, eachassociated with a respective one of a plurality of site record sources.16. The one or more servers of claim 14, the one or more processorsfurther operable to cause one or more instructions to be executed to:store contextual information for the site record, the contextualinformation including one or both of: the source, and a time at whichdetermination of the source-based confidentiality was last conducted.17. A non-transitory computer-readable storage medium storinginstructions executable by a server configured to cause a method to beperformed for determining a confidentiality for a site record, themethod comprising: identifying a site record for analysis; identifying asource for the site record; determining, based on the source, asource-based confidentiality for the site record; identifying, based onthe site record, a designated confidentiality for the site record;determining that the designated confidentiality is different from thesource-based confidentiality; and responsive to the determination thatthe designated confidentiality is different from the source-basedconfidentiality, storing the source-based confidentiality for the siterecord on a storage medium.
 18. The non-transitory computer-readablestorage medium of claim 17, wherein determining the source-basedconfidentiality level comprises: accessing a list of designatedconfidentiality levels, each associated with a respective one of aplurality of site record sources.
 19. The non-transitorycomputer-readable storage medium of claim 17, the method furthercomprising: storing contextual information for the site record, thecontextual information including one or both of: the source, and a timeat which determination of the source-based confidentiality was lastconducted.
 20. A method of determining a confidentiality for a siterecord, the method comprising: identifying, at a computing device, asite record for analysis; identifying a source for the site record;determining, based on the source, a source-based confidentiality for thesite record; identifying, based on the site record, a designatedconfidentiality for the site record; determining that the designatedconfidentiality is not higher than the source-based confidentiality; andresponsive to a determination that the designated confidentiality is nothigher than the source-based confidentiality, continuing to use thedesignated confidentiality for the site record.